Content delivery networks (CDNs) have greatly improved the way content is transferred across data networks such as the Internet. A CDN accelerates the delivery of content by reducing the distance that content travels in order to reach a destination. To do so, the CDN strategically locates surrogate origin servers, also referred to as caching servers or edge servers, at various points-of-presence (POPs) that are geographically proximate to large numbers of content consumers and the CDN utilizes a traffic management system to route requests for content hosted by the CDN to the edge server that can optimally deliver the requested content to the content consumer. Determination of the optimal edge server may be based on geographic proximity to the content consumer as well as other factors such as load, capacity, and responsiveness of the edge servers. The optimal edge server delivers the requested content to the content consumer in a manner that is more efficient than when origin servers of the content publisher deliver the requested content. For example, a CDN may locate edge servers in Los Angeles, Dallas, and New York. These edge servers may cache content that is published by a particular content publisher with an origin server in Miami. When a content consumer in San Francisco submits a request for the published content, the CDN will deliver the content from the Los Angeles edge server on behalf of the content publisher as opposed to the much greater distance that would be required when delivering the content from the origin server in Miami. In this manner, the CDN reduces the latency, jitter, and amount of buffering that is experienced by the content consumer. The CDN also allows the content publisher to offload infrastructure, configuration, and maintenance costs while still having the ability to rapidly scale resources as needed. Content publishers can therefore devote more time to the creation of content and less time to the creation of an infrastructure that delivers the created content to the content consumers.
As a result of these and other benefits, many different CDNs are in operation today. Edgecast, Akamai, Limelight, and CDNetworks are some examples of operating CDNs that are responsible for the delivery of terabytes worth of content. FIG. 1 illustrates a representative infrastructure for some such CDNs. As shown in FIG. 1, the infrastructure includes a distributed set of edge servers 110, traffic management servers 120, and an administrative server 130. The figure also illustrates the interactions that CDN customers including content publishers have with the CDN and interactions that content consumers or end users have with the CDN.
Each edge server of the set of edge servers 110 may represent a single physical machine or a cluster of machines. The cluster of machines may include a server farm for a geographically proximate set of physically separate machines or a set of virtual machines that execute over partitioned sets of resources of one or more physically separate machines. The set of edge servers 110 are distributed across different edge regions of the Internet to facilitate the “last mile” delivery of content. The edge servers run various processes that (1) manage what content is cached, (2) how content is cached, (3) how content is retrieved from the origin server when the content is not present in cache, (4) monitor server capacity (e.g., available processor cycles, available memory, available storage, etc.), (5) monitor network performance (e.g., latency, downed links, etc.), and (6) report statistical data on the delivered content. The set of edge servers 110 may provide the monitoring information to the traffic management servers 120 to facilitate the routing of content consumers to the optimal edge servers. The set of edge servers 110 may provide the statistical data to the administrative server 130 where the data is aggregated and processed to produce performance reports for the delivery of the customers' content.
The traffic management servers 120 route content consumers, and more specifically, content consumer issued requests for content to the one or more edge servers. Different CDN implementations utilize different traffic management schemes to achieve such routing to the optimal edge servers. Consequently, the traffic management servers 120 can include different combinations of Doman Name System (DNS) servers, load balancers, and routers performing Anycast or Border Gateway Protocol (BGP) routing. For example, some CDNs utilize the traffic management servers 120 to provide a two-tiered DNS routing scheme, wherein the first DNS tier resolves a DNS request to the CDN region (or POP) that is closest to the requesting content consumer and the second DNS tier resolves the DNS request to the optimal edge server in the closest CDN region. As another example, some CDNs use Anycast routing to identify the optimal edge server.
The administrative server 130 may include a central server of the CDN or a distributed set of interoperating servers that perform the configuration control and reporting functionality of the CDN. Content publishers register with the administrative server 130 in order to access services and functionality of the CDN. Accordingly, content publishers are also referred to as customers of the CDN. Once registered, customers can interface with the administrative server 130 to specify a configuration and view performance reports.
Generally, a customer configuration identifies the content that is to be delivered by the CDN, the amount of CDN resources to provision, and the caching policies for the provisioned resources as some examples. However, the customer configuration cannot be deployed to one or more of the edge servers unless the edge servers are configured to support the customer configuration. To support the customer configuration, the edge servers are first configured with a base configuration that includes an operating system (OS), communication parameters (e.g., Internet Protocol (IP) address), and security parameters as some examples. Next, the edge servers are configured with a set of applications that execute or otherwise implement the customer configuration. Next, the set of applications are themselves configured for storage, logging, service attributes, and the like.
The problem for any CDN and any distributed platform is how to effectively deploy and manage the various configurations for hundreds or thousands of customers across hundreds or thousands of edge servers and how to ensure synchronicity across the edge servers. Maintaining synchronicity is complicated because a single customer configuration can be deployed to different edge servers, different edge servers can support different underlying applications and application configurations, and different edge servers can execute on different hardware. When a particular customer's configuration is updated, the update needs to be propagated to each of the edge servers that have been deployed with that customer configuration without breaking existing configurations on the edge servers and without extensive downtime to the servers. Similarly, when an application is updated, the update needs to be propagated to each of the edge servers that are installed with that application without breaking the customer configurations that execute using that application and without extensive downtime to the servers.
Prior art techniques for deploying configurations and maintaining synchronicity across edge servers of a CDN have included manually configuring the edge servers, using portals to remotely configure the edge servers, and using a central database to push configurations to the edge servers. Some such techniques are identified in U.S. Pat. No. 6,868,444 entitled “Server configuration management and tracking”, U.S. Pat. No. 6,842,769 entitled “Automatically configured network server”, and U.S. Pat. No. 6,789,103 entitled “Synchronized server parameter database”. Each of these techniques has various shortcomings that render the techniques less than ideal for configuring edge servers of a large scale CDN or other distributed platform. Some of the shortcomings include (1) extensive downtime while reconfiguring a server, (2) multiple users modifying the same configuration at the same time without proper integrity controls, (3) scalability, (4) overwriting isolated customizations when propagating an update, (5) overwriting a prior configuration when propagating an update without the ability to revert to that prior configuration, and (6) inability to perform incremental updates to a configuration as a result of having to overwrite entire configurations when propagating an update.
Accordingly, there is a need for improved systems and methods to automatedly update and manage the configurations that are deployed to the edge servers of a CDN or other distributed platform. There is a need to rapidly perform such updating while being able to scale to support large numbers of edge servers and large numbers of configurations. There is a need to maintain configuration integrity and consistency across the edge servers while being able to retain customizations that have been applied to already deployed configurations. There is also a need to retain previous configurations to be able to revert to any such previous configurations when needed.